The zmq_event_receive is currently only consumed by the Waiter, signal, and is really only used in the wait method when the accept_block_notification is true. This only happens when wait is invoked in the main loop in electrs.rs which controls mempool updates like you noted in your description.

One issue I see with this approach is the overhead from the increased number of Mempool::update calls. The hashblock notification isn't being used as a way to detect if a transaction hash was added to the mempool, it's a way to communicate to the main loop that we need to remove confirmed txs from the mempool. Whenever it's called, we get all the txids from the node's mempool, remove the txids in our mempool that are no longer present, and make additional calls to retrieve the transactions we don't have. To avoid updates from being invoked for every tx, I'd suggest filtering for just block events.

I agree with @Randy808 that triggering a mempool snapshot sync for each mempool update seems excessive. The mempool can update faster than a sync round takes to complete, which means that it'll basically be syncing the mempool non-stop.

We could throttle it (the cap depends on how long a sync round can take which we can check in prometheus, but I would say around 1-2s seems sensible), but that doesn't really buy us much over the current 5s interval. With individual transaction processing (something I started working on a long time ago and will be reviving soon) ZMQ can be used to make mempool syncing real-time and efficient, but with the overhead of the current snapshot sync implementation we can't really push the interval much lower than it is now.

The main benefit (assuming throttling) is that we can (somewhat) decrease the interval without introducing additional unnecessary work when the mempool is quiet, like we would if we just decreased the periodic polling interval. But I'm not sure if its worth it.